In process automation technology, field devices are frequently used, which serve for registering and/or influencing process variables. Examples of such field devices are fill level measuring devices, mass flow meters, pressure meters, meters for measuring temperature, etc., which register the corresponding process variables fill level, mass flow rate, pressure, and temperature. Serving for the influencing of process variables are so-called actuators, which, e.g. as valves, influence the flow of a liquid in a section of pipeline.
The field devices are usually connected to a data bus, and are, as a rule, connected with a central control-, or engineering-, system, which controls the entire process flow and/or enables a direct access to the individual field devices. In the control system, the measured values of the different process variables are evaluated and/or monitored, and appropriate actuators are correspondingly activated for influencing the process. Data transmission between field device and control occurs according to the known international standards for field busses, such as e.g. Hart, Foundation Fieldbus, Profibus, CAM, etc.
Today's automated plants frequently involve a large number of different field devices of a widest variety of manufacturers. Before startup and/or during operation, adjustments must occur at the field devices. These adjustments must frequently be made on site. To this end, the individual field device manufacturers provide different configuration programs for the different devices. Becoming competent with the different programs, including the different operating philosophies, demands extreme effort and time on the part of the user.
The parametering of individual field devices or the configuring of certain groups of field devices in an automated plant having a multiplicity of field devices is extremely complex and expensive, because of the various communications interfaces and the required protocols. The configuring, operating, and maintaining of a field device in an automated plant should be considerably simpler to perform. Desired is the integration of field devices into control systems or engineering applications via a Plug and Play capability, such as is already known e.g. for printers in Windows environments.
Various field device manufacturers have, therefore, come together in PNO (POFIBUS Nutzerorganisation e.V.), for the purpose of enabling a simpler handling of field devices. The field device manufacturers develop special software modules for their field devices. These software modules are delivered with the field devices to the customers. Each software module encapsulates all data and functions of the particular field device and represents, in principle, a black box. Additionally, the device manufacturer can integrate into these software modules its own “look and feel”. I.e., the user interface always looks the same to the user, independently of the particular application. The application program, which serves e.g. for configuring, visualizing, operating and maintaining the different field devices, accesses the particular software modules of the field device via a defined interface. One possibility is the FDT/DTM interface specification, as given in the Profibus Guideline-Order No. 2.162, volume 3, of November 2000, which can be obtained via the PNO, Karlsruhe, Germany (www.profibus.com). The content of such guideline is incorporated here by reference.
At the moment, corresponding software modules are available only for a few field devices. For a large number of field devices, the software modules still have to be produced by the pertinent manufacturers. One possibility is to convert available device descriptions by means of compilers, or generators, into corresponding software modules.
The available device descriptions, however, do not exist in a uniform form, or language. There are PDM device descriptions, HCF device descriptions, as well as company-specific device descriptions stored in internal company databases. For each of these categories of different device descriptions, a separate compiler is necessary.
Disadvantageous in the case of such method is that one must generate different compilers for different categories of device descriptions. A further disadvantage of such method is that, in the case of changes, all utilized compilers always have to be revised, in order to prevent inconsistencies. This makes the generating of software modules for field devices by means of present device descriptions very complex.